Re: traversing through skip of skips llandale - Fri Sep 28 14:32:04 EDT 2012
This looks familiar...
I don't see why you would get the error; but maybe because of the "x" data type error combined with the inside "get" error in the code.
So far so good:
-
I see your Skip "S_attValueListMod" has KEY of type "int" and DATA of type "Skip".
-
I see the KEY is some arbitrary ordering of modules
-
I see the DATA is SKIP information about this module
-
I see your embedded Skip "sInner" has KEY of type "string" and DATA of type "int".
-
I see the KEY is "Attribute Name"
-
I see the DATA is how many objects have a value for that attribute.
-
I see you use the KEY and DATA for both Skips consistently between "putting" and "getting".
However:
-
I see your "for x in sInner do" loop has "x" as type "string" when it is the DATA for sInner which is type "int". I don't think that matters since you never use "x" after that.
I know I'm a bit <invalid content detected, rhymes with "banal"> but I now routinely do this:
Skip S_attValueListMod = create() // KEY: 'int' Module Order; DATA: 'Skip' sInner below.
Skip sInner = null // KEY: 'string' NameAttr; DATA: 'int' Number of objects with some value for that attr
If I don't do that I get lost when I have more than one Skip to keep track of. When Reviewing code, I keep that in one window and find all references to the Skip to make sure I'm using it consistently. There seems to be a lot of folks who don't need that crutch.
Anyway.
-
You search a Skip by searching for the "Key".
-
If you want to find attribute Name then: <if (find(skp, Name, Count)) then I found it.>
-
You can loop through all values of a skip:
-
for Count in skp do
-
{ NameAttr = (string key skp)
-
It is understood this loop retrieves in Key sorted value. For KEYs of string/int/real/char the order is self evident. For KEYs that are handles Module/Object/Link/Etc the ordering should be presumed to be Random, although in some cases it is in the Order in which the Handle was allocated and in others it is the order in which the structure was created (e.g. oldest "Module" comes first).
-
Since your outer loop has 'int' key ordering, you CAN combine these, although I don't see an advantage.
-
for (Count = 0; Count<MaxMods; Count++)
-
{ find(skp, Count, sInner))
I'm guessing your 2nd page wants to look like this:
int Index, Count
bool FoundAttr_Any, FoundAttr_Valued
for sInner in S_attValueListMod do
{ Index = (int key S_attValueListMod) // Index type 'int' is KEY; sInner type 'Skip' is DATA
FoundAttr_Any = false
FoundAttr_Valued = false
for Count in sInner do
{ NameAttr = (string key sInner) // NameAttr type 'string' is KEY; Count type 'int' is DATA
FoundAttr_Any = true // Found some attribute
if (Count > 0)
{ FoundAttr_Valued = true // Found some attribute with some values
break // No need to keep looking, but it doesn't matter if you do
}
}
if (!FoundAttr_Any) then indicate in [lstDspAttr] Module #Index has no Attributes
elseif(!FoundAttr_Valued) then indicate in [lstDspAttr] Module #Index has no populated Attributes
else indicate in [lstDspAttr] Module #Index has at least one Attribute with a non-null value
}
Notice we are setting the flags false ABOVE the loop; and true if we find a favorable condition INSIDE the loop. That is routine (but not always) when the flag is consulted AFTER the loop.
-Louie
|